@sabberworm Anything else you'd like to see with this PR?

Thanks for the input @westonruter. Sorry for the long response time, I had been away on holiday.

While this does solve one of the long-standing gripes I’ve had with selector parsing, it does not solve all of them and I don’t think it’s a particularly elegant solution and it’s not the direction I want to pursue.

What I would like to see is to see the Selector class expanded to becomes an interface with subclasses for every type of (combining) selector there is, so that every selector is stored as an instance instead of a string.

So the selector .a + :not(#b) + [c] ~ foo|.d span > *:root, would decompose into:

new AdjacentSiblingCombinator(
	new ClassSelector('a'),
	new Negation(
		new IDSelector('b')
	),
	new GeneralSiblingCombinator(
		new AttributeSelector('c'),
		new DescendantCombinator(
			new NamespaceSelector(
				'foo',
				new ClassSelector('d')
			),
			new ChildCombinator(
				new TypeSelector('span'),
				new Combinator(
					new UniversalSelector(),
					new RootSelector()
				)
			)
		)
	)
);

Note: this is just a suggestion. Maybe the Combinator could be replaced with a simple array and maybe it’s not a good idea to let the same combinator have more than two elements (like the AdjacentSiblingCombinator in my example, which could instead be transformed into two nested ones). And maybe we don’t need to nest them, just store combinator and simple selector in an array side-by-side.

However what this requires is actually parsing and understanding the selector. And I think string substitution, even when done right, is a poor substitute (pun intended) for that.

Actually parsing selectors would finally also fix the following:

.some[selectors-may='contain-a-{'] {}

which parses neither with nor without your fix.

Thanks. You're right. My fix is more of a bandaid than a permanent solution. I wasn't sure that you intended to actually have the selector themselves parsed as well. That being the case, then indeed my fix isn't ideal.